% !TEX root = main.tex

\subsection{UML Profiles}
\label{sec:umlprofile}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.6\textwidth]{./figures/UMLsec}
	\caption{UMLsec Y-Process}
	\label{fig:UMLsec}
\end{figure}

\begin{figure}[tb]
	\centering
	\includegraphics[width=0.6\textwidth]{./figures/secureUML}
	\caption{secureUML Y-Process}
	\label{fig:secureUML}
\end{figure}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.6\textwidth]{./figures/SECTET}
	\caption{SECTET Y-Process}
	\label{fig:SECTET}
\end{figure}


Historically, the first emerged \mds methodologies were using \UML profiles to model both business and security concerns. 
These approaches mostly differ in the profiles used.
\newline

\smallskip\noindent \textbf{Security Concerns}\\
J\"urjens proposed \emph{UMLsec} \cite{springerlink:10.1007/3-540-45314-8-14,springerlink:10.1007/11804192-4},
an annotated \UML model for security modeling and analysis. In \emph{UMLsec}, security concerns are system integrity, confidentiality, \etc. 
For example if we consider mobile systems, the security requirement \emph{trusted communication} means the system is resilient regarding various threats of untrusted channels, \eg package lost, data infection, \etc.

Basin \etal have proposed  \emph{secureUML} \cite{Basin:2011:DMS:1998441.1998443,Basin:2003:MDS:775412.775425,Basin:2006:MDS:1125808.1125810}, a \UML profile for security engineering.
\emph{secureUML} is designed to model and analyze \rbac (Role-Based Access Control). 
\newline

\smallskip\noindent \textbf{Modeling and Analysis}\\
\emph{UMLsec} considers a \UML extension to develop secure systems. 
This proposal uses the majority of \UML diagrams to model security aspects, mainly those that refer to confidentiality and integrity. 
For example, State Diagrams model, the dynamic behavior of objects, and Sequence Diagrams are used to model protocols. 
Deployment Diagrams are also used to model links between components across servers.
This methodology also incorporates the translation of \emph{UMLsec} models defined for the introduction of patterns into the design process.
The security of a subsystem specification is analyzed by modeling the behaviors of the potential attacker, hence, specific types of attackers, that may attack different parts of the system in a specific way.
These attackers are modeled separately as independent \emph{Adversary Machines}.
Model composition is enabled by means of a mapping, which J\"urjens calls
\emph{renaming}. Renaming associates an \emph{Adversary Machine} with the system's
behavioral model by mapping the \textit{stereotypes} with \textit{tags} and
\textit{constraints}. The composed model is called \emph{Concretized Model} in \emph{UMLsec}.
\emph{UMLsec} allows performing security analysis on the
enforcement infrastructure. The \emph{Control Flow Graph} generated from the concretized
model is compiled to first-order logic axioms which can be verified by the
theorem prover included in the toolset.

\emph{secureUML}, derived from \mof(Meta-Object Facility), consists of:
\begin{itemize}
	\item A \emph{security modeling language}, \ie \emph{secureUML}, for expressing
	security policies (\rbac);
	\item A \emph{system design modeling language}, namely \emph{componentUML} or
	\emph{controllerUML}, for constructing design models against concrete
	scenarios;
	\item A \emph{dialect} provides a bridge by defining the connection points for
	integrating security models and system models.
\end{itemize}
Both \emph{secureUML} or system design modeling languages incorporate an
explicit \emph{abstract syntax} which defines the language primitives used to
build models and a \emph{concrete syntax} which is the notation defines
representation of these primitives.
The \emph{dialect} is a mapping between the abstract syntaxes of system
design modeling language and \emph{secureUML}. It uses sub-typing to classify
construct elements of the \rbac models expressed in \emph{secureUML} as
belonging to subtypes in business models expressed in the system design modeling
languages. As an example, it connects elements in the system design model
representing actions and resources to their corresponding elements in the
security model.
\newline




\smallskip\noindent \textbf{Transformations}\\
\emph{UMLsec} produces the infrastructure \emph{Control Flow Graph} by transforming from the concretized model, via a tool called \emph{aiCall}.
\newline

\smallskip\noindent \textbf{Traceability}\\
\emph{UMLsec} models security concerns as \emph{Adversary Machines}, 
so that threat risks are analyzed by reasoning on potential attacks from those adversaries.
In order to perform such reasoning a Prolog-based tool automatically
generates an \emph{attack sequence} attempting to violate the security
requirement. The attack can then be examined to determine and remove the
weakness of system. This mechanism allows traceability of \emph{UMLsec}.

The schemas of \emph{UMLsec}, \emph{secureUML} and \emph{SECTET} can be synthesized
in  \fig \ref{fig:UMLsec}, \fig \ref{fig:secureUML} and \fig \ref{fig:SECTET} respectively.
\newline


\jackin{start here \dots}






%As shown in the ``Modeling'' column in \tab \ref{tab:comparison}, \emph{UMLsec}, \emph{secureUML} and \emph{SECTET} use \UML profiles to model both business and security concerns.
%The modeling capability only varies among these \mds methodologies according to their designed profiling for a certain security concern,
%\ie \emph{secureUML} and \emph{SECTET} modularize \emph{access control} (Class Diagram) while \emph{UMLsec} models \emph{threats} as adversary machine (State Diagram).

Criticisms quickly come out since the disadvantages are evident. 
First, profiling \UML limits the modeling capability for wide range security concerns: adapting them to new security concerns beyond their original designed target is difficult, if not even impossible \cite{sanchez:jucs-15-15}. For example, \emph{secureUML} works well on \rbac, but it is hard to model and reason about ``message-lost'' threat in mobile communication scenario.
Second, using general-purpose modeling languages like \UML hinders reusability, although it favors communication between models. However, adapting these profiles for new systems requires a huge effort for systems for which security is not well standardized \cite{JCISIMA:MA:MDS}.



















\smallskip\noindent \textbf{Modeling.}\hspace{0.5cm} 


\smallskip\noindent \textbf{Transformation.}\hspace{0.5cm} The composed model
can be amenably transformed basic system code or infrastructure, \ie Enterprise
JavaBeans (EJB) or or alternatively Microsoft Enterprise Services (.NET).

\smallskip\noindent \textbf{Analysis.}\hspace{0.5cm} The \rbac policy
verification can be performed by queries of \textsc{Ocl} (Object Constraint
Language) constraints defined on the composed model
\cite{Basin:2009:AAS:1512996.1513226}. There exists no clearly developed
mechanism for traceability.

The schema of \emph{secureUML} may be synthesized as a 
\emph{Y-Process} as shown in \fig \ref{fig:secureUML}.





\subsection{SECTET}
\label{sec:SECTET}



Breu \etal have proposed \emph{SECTET} \cite{mdse-breu-jos-2007,10.1007/s10009-007-0045-y},
a framework based on a \UML profile for business and security modeling and
analysis.

\smallskip\noindent \textbf{Security Concerns.}\hspace{0.5cm} \emph{SECTET} is mainly designed to deal with
access control.

\smallskip\noindent \textbf{Modeling.}\hspace{0.5cm}  The \emph{SECTET} framework consists of a modeling
component \emph{SECTET-UML} and an Object Constraint Language (OCL) style
predicative language called \emph{SECTET-PL}. The \UML profile
(\emph{SECTET-UML}) is used to model business requirements and static security
requirements, such as roles and their hierarchies. Dynamic security requirements
are defined as \emph{Type Navigation Expressions} and {Permission Predicates}
expressed in \emph{SECTET-PL}.
 
The model composition is an annotation process which integrates
\emph{SECTET-UML} models with dynamic security requirement expressions in
\emph{SECTET-PL}, to form a platform independent application model
(\textsc{Pim}), on which platform independent security analysis can be
performed;

\smallskip\noindent \textbf{Transformation.}\hspace{0.5cm}  With the necessary platform information, the
platform independent application model (\textsc{Pim}) can be transformed to XACML
meta-model (M2M) and later transformed into XACML policies (M2C).

\emph{SECTET} conforms weakly to our Y-Model proposal given that, comparing with
\emph{secureUML} where the business and security source code is partially
generated, only XACML policies can be produced from the model-to-code transformation.

\smallskip\noindent \textbf{Analysis.}\hspace{0.5cm}  Similarly to \emph{secureUML}, in \emph{SECTET} access
control verification may be done on the composed platform independent model by
querying the model using \textsc{Ocl} constraints. No traceability as
defined in the Y-Model exists in this methodology.

The synthesis of \emph{SECTET} methodology as a specific \emph{Y-Process} is
shown in \fig \ref{fig:SECTET}.
 


